This PR will take a while for me to review due to the implementation complexity and the need to take multiple difficult decisions so I'm lowering its priority in favour of reviewing other PRs.

I've added the label though. Will get back to this PR later when I have enough time.

My proposal is to wait for the implementation of #128 first to see how it affects the design of this issue. As mentioned before, we would like to avoid the total number of GitHub API queries. So a potential solution would be to query GitHub API again for the list of all releases if we don't find the specified tag.

As for the specific implementation of this issue, I propose the following weights for the Levenstein distance algorithm:

• EDIT_DISTANCE_THRESHOLD = 4 (as current)
• Add weight: 1
• Delete weight: 1
• Replace weight: 2 (aka add + delete; or we can even remove the replace case entirely from the algorithm if it's present and it'll be simulated by add + delete automatically)

The idea behind this is to suggest similar tags. I think it would be weird to suggest version 7.8.9 when the user has specified 1.2.3. The common case is the absence or presence of the v prefix. Or a different minor version (e.g. 13.0.1 vs 13.1.0).

If there's no release within the edit distance threshold, we could just output all the possible releases with some of their info (e.g. the release date) so the users could select the desired release quickly.

Hey @chshersh,

I propose to drop that PR in favor of #135 - even though showing the possible tag is cool, implementing it makes the codebase more complicated and unreadable.

The #135 PR handles both "repo not found" and "tag not found" cases, so it'll be up to the user to check the available tags and choose the one they need.

@crudiedo I agree with your assessment 🙂
Feel free to close this PR then 👍🏻

Closed due to #135